When constructing an application, a software developer typically creates the software components by writing “imperative code” using a development language, such as C#. In creating the imperative code, i.e., the software code that gives the software component its function, the developer must create links between all the components through calls or other constructs. For any functionality provided by an application, the software developer generally creates the code for all the different software components that perform the application specific functions and manually codes the interconnections between the software components that rely on each other to complete tasks. The software developer creates user interfaces, data constructs, and all the required operations for the interactions between the user and the application.
In most applications, the user interface, operations, and data constructs are application-specific. Thus, to create an application, a software developer typically creates a significant amount of code to implement the specific user interface, operations and/or other constructs. In addition, the software developer generally organizes and creates all the interrelationships between the different pieces of software. As a result, to create any application, a software developer must be significantly skilled in using the underlying languages used to create applications.
A particularly complex application development issue arises in dealing with transactions. Transactions relate to the communication (and typically the transfer of data) between a client and a server, or, as contemplated herein, a data client and a data store, where a data client is a UI element that allows access to data in one or more data stores. Applications for manipulating such data through transactions frequently make use of “atomic” transactions. An atomic transaction is a set of operations that follow an “all or nothing” principle, in which either all of the operations are successfully executed, or none of them is executed. For example, in a system for performing money transfers, information must be guaranteed to be fully updated. If funds are transferred between two accounts, one account cannot be credited if the other is not debited by the same amount. Recording the credit, and recording the corresponding debit therefore require atomic, “all or nothing” committal of the operations.
Previously, in order to perform an atomic transaction, typical applications relied on a two-phase commit model. In such a case, data is held/buffered temporarily for committal. During the first phase, assurances are sought that the buffered data can be committed atomically to all data stores that hold the data. In the second phase, if assurances are received, then all data stores that hold the data will commit the changes. If one or more of the data stores are not able to commit, then the operation is aborted, and the updates in the data view are lost, where the data view is a type of data client that provides read and/or write access to data in a database. Losing such data forces the user to re-enter the data, wasting time and resources.
It is with respect to these considerations and others that the present invention has been made.